The ANDROID™ operating system, available from Google Inc. of Mountain View, Calif., is a LINUX-based operating system designed primarily for touchscreen mobile devices such as smartphones and tablet computers. The ANDROID operating system uses a LINUX kernel at its core, and also provides an application framework that software developers can use to implement ANDROID operating system applications and services. The ANDROID operating system additionally provides a native middleware layer between the LINUX kernel interface and the ANDROID operating system applications and services that execute at the higher application layer to enable easier cross-platform development for deploying the same applications or services across different types of hardware devices.
This middleware layer includes a set of shared libraries that provide services such as data storage, screen display or multimedia, and are compiled to machine language to enable services to execute quickly. The middleware libraries implement device-specific functions, so applications and the application framework need not concern themselves with the variations between devices running the ANDROID operating system. The middleware layer also supports a specialized version of the Java runtime to simplify cross-platform development. In particular, it provides the Dalvik Virtual Machine (DVM) and its core Java application libraries. Applications or services implemented by developers can be compiled from Java (or other supported languages) to a byte-code that can be run by the DVM.
Although the middleware layer simplifies application development, it also adds significantly more complexity to the overall ANDROID operating system. This additional complexity can be exploited by applications or services programmed to perform malicious tasks (malware) or execute malicious code (malcode).
By way of example, malware or malcode can exploit Inter-Process Communications (IPC) or Inter-Component Communications (ICC) to attack sensitive applications and their data. Referring to FIG. 1, each application 10, 12 is executed in a respective DVM 14, 16. When launched, each application corresponds to an instance of a DVM. Each DVM 14, 16 is mapped into a dedicated process 18, 20 running in User Mode 22 in the LINUX layer 24. In the ANDROID operating system, applications can communicate with each other using IPC mechanisms. The standard mechanism in the ANDROID operating system to implement IPC is though the Binder framework. The Binder framework has the facility to provide bindings to functions and data from one process to another. The Binder framework in the ANDROID operating system is provided in three levels. At the application layer 42 there is an Application Programming Interface (API) 26, 28 to enable applications to communicate with each other. The ANDROID Interface Definition Language, which is part of this API, allows developers to define the interface for an ANDROID operating system service and an AIDL parser generates the Java client code that the service clients can use and a service stub that the developer can use to create the service implementation. At the native middleware layer 44 a Binder class 30, implemented using the C++ language, provides the user space facilities to be used by the applications via Java Native Interface (JNI) and interacts with the Binder kernel driver 32, which is part of the customized LINUX ANDROID operating system kernel. The Binder kernel driver 32 carries out the message passing between processes and provides a shared memory facility. The driver sits behind a special device, /dev/binder, and can be used through various system calls, such as open and ioctl, to enable processes to communicate with each other.
As shown in FIG. 1, the IPC mechanism can be described in two layers. At the the ANDROID operating system layer 46, when Application 1 (10) sends an IPC through its AIDL API (26) as shown at 34, the binder code 30 in the middleware will take care of the delivery of the request to the destination Application 2 (12) as shown at (36). At the LINUX layer, this operation is translated into a sequence of system calls (open and ioctl) executed by Process 1 (18) (corresponding to Application 1) using the binder kernel driver (dev/binder) 32 as shown at (38). The request is then forwarded to Process 2 (20) (corresponding to Application 2) as shown at (40).
In conventional UNIX and LINUX operating systems, security systems such as SELinux or the LINUX Security Modules have been proposed in the form of a kernel module that can trace a process to enforce security policies. This involves recompiling the kernel image in order to register the module and to be able to eventually load it. Additionally, as new applications are launched by the user via a shell command line, the monitoring module is able to link the correct security policy to the newly launched process by analyzing the command line arguments. Such security systems do not work effectively on the ANDROID operating system, which uses a distinctly different way of launching and managing Applications. It is also desirable to have a security system for the ANDROID operating system that does not require recompilation of the LINUX kernel.
In the above security systems, malicious applications can fool the security system by converting into a different application than the one launched via the shell command line arguments. This means the security system associates an incorrect set of security policies with the launched process thinking that it is the application specified by the initial shell command line arguments.
The phrase “OS virtualization” refers to a technique to allow multiple instances of an OS or isolated user-spaces to share the same hardware resources of a device. Each OS instance runs in complete isolation from the other instances. Typically, virtualization can be achieved using three alternative techniques: Full virtualization using binary translation, Paravirtualization, or Hardware-supported virtualization.
Full virtualization is achieved by automatically translating the binary instructions from the guest OS to low level instructions to achieve the effect of virtualizing the hardware. Although full virtualization does not require modifications in the guest OS, its main drawback is the extra computation resources required to translate the instructions. This can be problematic in devices with constrained power resources as it reduces operational time on a single battery charge.
Paravirtualization refers to a technique where the guest OS is modified in such a way that instead of executing the normal instructions it will execute a set of special instructions to communicate with the virtual environment on which it is deployed. Paravirtualization increases performance but at the cost of extensive modifications of the guest OS. This means that specifically to the case of ANDROID OS, a specific image of the ANDROID OS needs to be developed and maintained.
Hardware-support virtualization requires a special set of instructions to be fully supported by the CPU.
There are three main drawbacks common to all three virtualization approaches above. First, they are coarse-grained in that they apply virtualization at the level of an entire OS image. Sometimes it is only necessary to isolate a single process from the rest of the running services, not the entire OS. Second, they do not provide enhanced security control. Virtualizing a guest OS does not mean to make it more secure. The same security level as in the plain OS will be replicated for each instance of the OS. If an OS instance is compromised by a rouge application that contains malware, all the applications and resources within that OS instance will be exposed to that application. Unless the OS itself is able to cope with such threats, virtualization alone will not provide an extra level of protection. Third, the above virtualization techniques exhibit static behavior in that the virtualization is only concerned in executing instructions to partition the underlying hardware for the different OS instances. No dynamic decisions are made.
In this specification where reference has been made to patent specifications, other external documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the various embodiments. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art.